home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000450_marca@wintermu….ncsa.uiuc.edu _Mon Dec 7 08:22:49 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  5KB
  1. Return-Path: <marca@wintermute.ncsa.uiuc.edu>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA10206; Mon, 7 Dec 92 08:22:49 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA01237; Mon, 7 Dec 1992 08:36:08 +0100
  6. Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA18698
  7.   (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Mon, 7 Dec 92 01:36:03 -0600
  8. Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
  9.     for @newton.ncsa.uiuc.edu:Guido.van.Rossum@cwi.nl id AA06202; Mon, 7 Dec 92 01:37:12 -0800
  10. Date: Mon, 7 Dec 92 01:37:12 -0800
  11. From: marca@ncsa.uiuc.edu (Marc Andreessen)
  12. Message-Id: <9212070937.AA06202@wintermute.ncsa.uiuc.edu>
  13. To: Dan Connolly <connolly@pixel.convex.com>
  14. Cc: Guido.van.Rossum@cwi.nl, marca@ncsa.uiuc.edu (Marc Andreessen),
  15.         www-talk@nxoc01.cern.ch
  16. Subject: Re: The spec evolves... 
  17. In-Reply-To: <9212070617.AA12781@pixel.convex.com>
  18. References: <9212070617.AA12781@pixel.convex.com>
  19.     <9212070641.AA05810@wintermute.ncsa.uiuc.edu>
  20.  
  21. Dan Connolly writes:
  22. > Good point. I didn't mean that we should make the physical distance
  23. > to the link destination known to the user. But I think users would
  24. > benefit from knowledge about the logical distance -- i.e. is
  25. > it part of the same node, part of the same document, or in some
  26. > other work completely? Is it more specific or more general
  27. > than this node?
  28.  
  29. Maybe a compromise: if linking to a point in the same document, color
  30. the anchor orange; if linking to a point on the same server, color it
  31. red; if linking to somewhere else entirely, color it violet.  Or a
  32. variation on that theme.  This wouldn't require changing HTML and
  33. wouldn't be too obtrusive to those of us who like transparency.
  34.  
  35. > [Discussion on what to do with links to GIF files.]  So perhaps it's
  36. > not the HTML data format that's doomed, but the <A> element. I guess
  37. > the lesson is: you can't teach an old element new tricks.
  38.  
  39. I think looking at the file extension will solve 95% of the cases
  40. (that's what extensions are for, after all).  The remaining 5% could
  41. be addressed by Content-Type.  The browsers should be brought up to
  42. speed.  That's one approach -- just getting multimedia out the door
  43. and merged into the current HTML spec calls for the simplest solution
  44. possible, at the moment.
  45.  
  46. > Counterpoint: when the design is complete, performance-critical code
  47. > can always be written in C and added as a module. In the mean time,
  48. > the benefits of rapid-prototyping outweigh the performance
  49. > penalties.
  50.  
  51. Yeah but, yeah but, once something is written with rapid prototyping
  52. in mind and turns out to work, odds are it's going to be *the*
  53. implementation, as its implementor goes on to bigger and better
  54. things.
  55.  
  56. > I don't mean to base the W3 architecture on Python -- only some
  57. > implementations.
  58.  
  59. Right.  Those implementations then will be (no offense to the Python
  60. folks intended, but here it comes...) chained to Python, which will
  61. put an instant damper on their general usefulness -- they're never
  62. gonna be merged into anything else and thus made more useful, unless
  63. that something else uses Python also, which (as is the case with all
  64. the rest of these systems) is just plain doubtful.
  65.  
  66. > Viola and tk/tcl: These try to do what's already been done in
  67. > the Xaw and Motif toolkits, and they don't do it as well. (I suppose
  68. > this is your point...)
  69.  
  70. Yup.
  71.  
  72. > Midas: This is a specially designed language highly suited to it's
  73. > purpose. Only the highest level of code in the Midaswww browser is
  74. > written in Midas. All the rest is reusable. Tony did a heck of a
  75. > job.
  76.  
  77. I agree with the latter point, but not the former.  There's very
  78. little reusable code in Midaswww.  I spent quite a bit of time trying
  79. to rip the SGML widget out and use it separately, and it's just not
  80. possible with the current Midaswww architecture.
  81.  
  82. > VUIT: how did this get in there?
  83.  
  84. It (or something similar) is being used to generate UIL code for
  85. Midaswww, which counts as another toolkit in my book, since I can't
  86. effectively edit it by hand -- despite the fact I know Motif a lot
  87. better than I'd like to, very little of my existing knowledge carries
  88. over.
  89.  
  90. > NeXT: I'd drop X/Xt/Xaw for NextStep in a second if it was an
  91. > option. NextStep isn't free, so it hasn't proliferated like X.
  92. > That's pretty much the end of the story.
  93.  
  94. Agreed on all counts.  Again, my point.
  95.  
  96. I'm not arguing *against* special toolkits and builders in the
  97. abstract -- I think they're great, for the lone programmer.  But it's
  98. just plain a fact that there's nothing standardized about them;
  99. they're not available on most systems; they're not going to make code
  100. reusability practically possible, and their use causes too much
  101. reinventing of the wheel.
  102.  
  103. Cheers,
  104. Marc
  105.